Business Analyst Community & Resources | Modern Analyst

Why I Don't Use BPMN

Jarett Hailes — Wed, 10 Feb 2010 01:59:00 GMT

First off, let me just say that I really like the BPMN standard, especially the 2.0 Beta specification. I find the notation to be a powerful and expressive language that takes into account not only the standard elements in business processes but also considers all sorts of interesting possibilities that may arise. I think the new Choreography and Conversation diagrams and additional event types open up new ways to describe intricate processes and collaborations between various individuals and organizations. Indeed, BPMN allows you to graphically model almost any situation that you can find in a business.

And I rarely get to use it.

According to the BPMN 2.0 Beta spec, there are two goals for BPMN. One goal “is to ensure that XML languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation.”

The other goal “is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.”

While BPMN does extremely well with respect to the first goal, I believe it does not live up to its second goal.

Business People Don’t Get BPMN Right Away

Whenever I stick a non-trivial BPMN model in front of actual business customers, I always get at least some questions. The number of questions varies depending on their sophistication and the number of times they’ve seen a BPMN (or similar) diagram before. BPMN leverages the typical flow-chart diagramming that nearly all business people are familiar with, but they’ve made several changes that make the their models anywhere from slightly confusing to downright unreadable for the layperson.

For instance, one of the most common questions I get is with respect to the fact that each pool has its own start and end processes as well as process flow lines. If there is interaction across the pools then a message flow is used. Most business people get overwhelmed with the additional flow lines and have trouble following the overall process path – usually when a hand off occurs between individuals or organizations you want to follow whoever received the handoff. With BPMN this is not always readily obvious since all pools continue along their own process flows. I could get around this by using only lanes instead of pools since lanes are not considered to be running their own processes, but then I’m not using lanes correctl. Each pool is defined as a “separate business entity or participant” while a lane is used to “separate the activities associated with a specific company function or role.”

BPMN Process Example

Other times people are thrown by the exceptions or compensation processes, since they are usually shown on the same page (although not necessarily). While I personally like these artifacts I often spend more time explaining why they are there than reviewing the accuracy of the actual process itself.

Over time I’ve been able to get some clients used to the notation, but if a new stakeholder is brought in I’m back at square one. To me this shows how BPMN is not ‘readily understandable’ by the vast majority of business people involved.

BPMN is a Great Precursor to BPEL

I definitely see how BPMN is an excellent tool to use if you’re preparing to leverage the Business Process Execution Language (BPEL) and have a BPEL Process Manager solution in place to automate business processes. The BPMN spec indicates that traditional models create “a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes.” BPMN has really been designed to address this gap, but has focused on the technical implementation side by sacrificing out of the box understandability for any given model.

From a solution standpoint this makes sense – if the goal is to in the end have automated business processes then you need to ensure that your model can translate into a language that is computer-ready. BPEL has been around for almost 8 years now and has gained a level of acceptance by software providers and businesses. Combined with the demand for lower labour costs wherever possible and there is clearly a need for non-programmers or extremely technical personnel to be able to leverage a graphical description of processes.

Like any other technically-driven language, BPMN is relatively generic, robust and flexible. In order to achieve its level of flexibility the language must be inherently complex to handle all the possible situations that could fall within the scope of the language’s use. While this is great from an implementation perspective it takes away from the ability for someone with little knowledge about the notation to be able to read a diagram.

When to Stick With the Tried and True Notation

In most situations (performing current state analysis, working through future state processes, validating requirements, etc.) that involve business people interacting with diagrams BPMN is a bit of overkill. When I’m not trying to create an automatable BPEL-driven business process I find that business people can almost universally understand a flowchart. This is something that most individuals have had exposure to at some point, and even if they haven’t there are so few different diagramming objects that it’s easy enough to pick up quickly (at the very least you don’t need a 226 page reference guide to figure out how to understand the chart)

While a flowchart may not be able to elegantly model complex business processes as well as BPMN, you can still get the job done by breaking up complex situations into several smaller component diagrams and then using the link object to move between the components. I find that this not only helps me ensure that each component chart is clear when I’m building the model, it also helps me work through specific sub-processes or exception cases with clients when I’m reviewing the details with them since it’s easier to focus on a single, relatively straightforward chart at a time.

Flowchart with Swimlanes Example

One part of BPMN that I’ve brought over to the flowchart world and use nearly every time is the swimlanes artifact. Having swimlanes helps everyone clearly understand the responsibilities and activities that each participant in the overall process plays, where the hand-offs are and what kind of information is going back and forth. I’ll often attach document or data elements when the flow goes across the lanes to show the details of the hand-off, which embeds a lot of the information you would typically find in a Data Flow Diagram (DFD) for the given business process. In fact, if you wanted you could roll up these messages and create a DFD if you have a need for that type of structured analysis.

While BPMN is a great way to prepare a business process for automation, it may not be the best choice when it comes to interacting with the business itself to document, verify and envision business processes.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Dispatches from the WCBA Conference: Jogging through the IIBA® BABOK®

Adrian M. — Tue, 17 Nov 2009 08:55:00 GMT

Here’s a dispatch from the first day at the World Congress for Business Analysts (WCBA).

I attended an all-day workshop titled “Get the Right Stuff, Fast: Jogging through the IIBA® BABOK® with the Requirements Roadmap” lead by Mary Gorman of EBG Consulting.

Mary is a Certified Business Analysis Professional™ (CBAP®) and works as Senior Associated for EBG Consulting, assisting teams to build the right products through exploring and confirming their requirements.

If Mary’s sessions was a jog, then this blog post will be a sprint – a very fast one, I might add!

The focus of the workshop was to:

Leverage the Requirements Roadmap to articulate requirements
Align requirements models to knowledge areas in the BABOK®
Create a set of interconnected requirements models to speed up the requirements development and successfully engage business users and customers.

During the session, Mary provided great insights on the business of “business analysis” specifically focusing on defining the scope of and modeling user requirements using the requirements roadmap:

You can get the PDF version of the requirements roadmap from EBG’s website.

During the session we raced (ok, just jogged) through the roadmap with pointers to sections in the various BABOK® knowledge areas:

Business Analysis Planning and Monitoring
Enterprise Analysis
Elicitation
Solution Assessment and Validation
Requirements Analysis
Requirements Management and Communication

Regardless of what methodology or techniques you use, Mary pointed out that it is important understand that we need to have a balanced perspective of the requirements through the lens of four fundamental model views:

Behavior: e.g. process, action, function, task, script
Structure: e.g. information, data, object
Dynamics: e.g. time, lifecycles
Control: e.g. business rules

The session slide included a nice Vann diagram of the four models with the control model being at the intersection of the behavior, structure, and dynamics models.

Jogging along… the session covered a number of techniques, including:

Stakeholder & Actors: Customer vs. User vs. Others => Ask: “Who?”

Glossary & Data Model: The building blocks for later constructs such as business rules => Ask: “What?”

Event-Response Tables: An effective tool to elicit user requirements => Ask: ”When?”

Use Case & Scenarios: Describe the flow of the actor-system interactions => Ask: “How?”

Business Policies & Business Rules: Statements that constrain some aspect of the business => Ask: “Why?”

The practical side of the workshop was the case study which forced everyone to roll-out their sleeves and put in practice the techniques discussed.

It was a cozy sessions with many chances for everybody to participate. Most of the session attendees got a free copy of the Software Requirements Memory Jogger.

- Adrian

Adrian Marchis
Publisher, ModernAnalyst.com

Could the Recession be Good News for Business Analysts?

Adrian M. — Mon, 09 Mar 2009 05:56:00 GMT

Most of us would agree that recessions are not a good thing – especially the one we are in right now.

But for those daring enough, tough times have can be moments of opportunity.

Many famous companies - such as GE, CNN, HP, Microsoft, Hyatt, FedEx, etc. - started during times of shaky economic conditions.

How did this happen?

They were started by people who recognized a market need and who worked diligently to fill that need. This is the key to starting and building thriving enterprises.

You may not be starting the next Microsoft but there are great opportunities for you, the business analyst, in these tough economic times.

Let’s take a look…

[1] In a down economy businesses tend to refocus on the bottom line: increasing efficiency, reducing costs, and identifying opportunities within the realm of their core competencies. Businesses are now ready to (perhaps forced to) slow down and take a closer look at their Business Architecture as well as employ Enterprise Analysis techniques in order to identify new opportunities.

Who is going to help these organizations with these tasks?

You got it!

It’s YOU, the business analyst…

[2] Many companies, for good or bad reasons, attempt to cut costs by outsourcing and off-shoring new system implementations and software development activities. To enable this, they must employ consultants or employees who understand the business needs/goals and interface with the outsourced providers.

Who do you think is best suited for this task?

You got it again!

It’s YOU, the business analyst…

[3] Have you heard of TARP, Stimulus, or Bailout?

Well – billions of dollars have been set aside to help banks, mortgage, and insurance companies. Attached to these dollars come many new rules, regulations, and conditions. The recipients and hopeful recipients of this money are busy trying to understand and implement the impact of these new rules into their business models, processes, and systems.

Who can benefit from this additional work?

Yep… the Business Systems Analyst, the Process Analyst, the Systems Analyst!

[4] Have you seen the various other changes being proposed though either specific plans or the new proposed budget for rest of 2009:

Numerous tax code changes – do you think the IRS, tax software companies, tax accountants, investment firms, etc. will have to change their models and business software? You bet they will!
Money to Modernize Air Traffic Control Systems – they’ll need top notch systems analysts. Are you one?
Enhance security at Major Ports – this will include many technology projects especially related to security. This might be a good niche for technical Bas who don’t mind learning a thing or two from a Security Analyst.
Align our Education with 21^st Century economic demands – this means science and technology… The might need folks who not only understand technology, know how technology can solve problems, but who can also communicate, teach, and mentor… Many business analysts are great at this!!!
Computerize America’s Health Records & Change the health care system. Do you have healthcare vertical domain knowledge? If you don’t get some, ‘cause this industry could potentially see some of the more drastic changes requiring new processes and business systems. By the way – we have a related free webinar coming: “Visualizing an Electronic Record System: A Case Study for BAs”
Developing and Disseminating Info on Effective Medical Interventions – $1.1 billion dollars have been slated for researching this data. Do you foresee the need for new systems based on solid Enterprise and Data Architecture? I do.
Etc., etc., etc.

It is up to you to identify these opportunities and niches which fit your skills and interests.

By the way – did you notice this month’s eJournal topic: Enterprise Business Analysis & Architecture!

This is the time to look at the big picture and identify trends which could either help or hurt you or your organization.

You mission, should you choose to accept it, is to identify these trends and changes and act appropriately.

This is NOT Mission Impossible… Enterprise Business Analysis is the discipline which will help you do just that.

Any thoughts of what opportunities might be there for you?

Would love to hear your ideas!

- Adrian

Adrian Marchis

Publishing Editor

ModernAnalyst.com